IBIS Macromodel Task Group Meeting date: 05 January 2021 Members (asterisk for those attending): Achronix Semiconductor * Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis Jared James Google: Zhiping Yang Intel: Michael Mirmak Kinger Cai Alaeddin Aydiner Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan * Todd Bermensolo Rui Yang Luminous Computing * David Banas Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SAE ITC Jose Godoy SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Fangyi said he had prepared some slides on the Redriver flow topic. ------------- Review of ARs: - Steve Parker to post Alaeddin's presentation to the ATM archives. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the December 15th meeting. David moved to approve the minutes. Randy seconded the motion. There were no objections. ------------- New Discussion: Redriver Flow Issues: Arpad noted that he had included Walter's summary of the issues, taken from the previous meeting's minutes, in the agenda email. He reiterated his request that we come up with some way to address the issues not just identify them. Fangyi shared a presentation "AMI Redriver flow". - slide 2: Problem Statement Fangyi said his presentation is largely based on Walter's recent proposal. It is based on the same assumptions, but it adds some modifications. The problem statement is: Assuming all models have GetWave and Init_Returns_Impulse=true (i.e., the Init function returns a modified IR), the only issue is that the redriver Rx/Tx Init doesn't have the cumulative upstream IR. So the Init cannot perform optimization properly and can't provide the IR needed for statistical simulations. David asked about the formulation of the problem statement. He said the redriver Tx Init doesn't receive the cumulative upstream IR, but he thought the redriver Rx Init did. Fangyi said the statement could be clarified. He added "and the terminal Rx" to the statement. He said that for any Rx after the first Redriver (either a subsequent Redriver's Rx, or the terminal Rx) the Init function does not get the cumulative upstream IR information. Ambrish asked Fangyi to clarify that there is no problem in the GetWave flow. Fangyi said not exactly, even in the GetWave flow some models may want Init to do some of the optimization. Ambrish said this behavior is a convenience or performance optimization used by the model maker. According to the standard, if the GetWave does everything it needs to do, it should not rely on what was passed into Init in order to get the right answer. Fangyi understood Ambrish's position, and he said this presentation is only concerned with the statistical flow. - slide 3: Conventions Fangyi introduced the notation conventions he uses for the channel IR, IR with the Tx effects, redriver Rx as opposed to a regular Rx, etc. - slide 4: Statistical Simulation with crosstalk The diagram shows two separate channels, each with a redriver. Fangyi said that there are many possible paths for crosstalk from one channel's Tx to the other channel's Rx, and the diagram doesn't show all of them. He noted, for example, that the diagram did not show the path from Tx1 directly to the Rx2. Fangyi said it would be more efficient for the EDA tool to compute all possible paths from one Tx to the other Rx if it has all the IRs (with Tx contributions, etc.) available for each of the sections. To do that, we would still want to pass the downstream IR information to the Txs (as in the existing flow). - slide 5: Solution proposal. Fangyi said his proposal is similar to Walter's proposal to start passing upstream info to Tx Init instead of downstream info. The difference is that instead of replacing the downstream IR with the upstream IR, Fangyi proposes appending the cumulative upstream IR to the end of the existing IR matrix. The function signature of Init would not be changed, there would just be an extra column added to the IR matrix passed into Init. Fangyi noted that if a Tx Init doesn't perform any optimization, then it doesn't need to use upstream cumulative response. Walter said that crosstalk was important, but for illustrative clarity let's not consider any crosstalk. He said in that case the new input to the Tx Init would be two columns, the first being the downstream (existing spec) and the second being the cumulative upstream. Fangyi agreed, and he said he was proposing two columns for the Rx too, the first being the immediate upstream (existing spec) and the second being the cumulative upstream. He said two columns were needed for the Tx and Rx to get all the IR terms the EDA tool needs to compute all the paths. Walter proposed what he thought was an even simpler solution (using the same no- crosstalk terms for illustrative simplicity). The input to every Init would be the cumulative upstream IR. The output of every Init would consist of two columns. The first would be the modified input IR (existing spec), and the second would be the IR of the equalization itself. Then there would be no need to add the crosstalk terms to the input IR matrix. The reason for doing so now is so that the model can apply the equalization of the Tx to each of the cross- talk terms. For the Rx, the second column would be the IR of just the analog front end (CTLE, AGC, FFE). The DFE doesn't apply to crosstalk. The EDA tool could then take care of all the convolution (crosstalk terms, etc.). Fangyi agreed, but he said one reason we might still need to pass in the crosstalk IRs in the IR matrix is that he thought some Rx models optimize their gain based on the amount of crosstalk. Arpad said he thought the suggestion to have Init return the IR of the equalization itself had been made several times in the past. He thought some IC vendors had been worried about revealing IP in that case. Fangyi agreed that when he had first gotten involved with AMI, he thought the reason we wanted the model to return a modified channel IR was to hide the equalization that was applied. David said that if this had been the case, then since deconvolution techniques could often be applied it's actually pretty easy to back out the equalization effects. He said concern about revealing IP should have more to do with the circuitry itself, and he thought AMI already protected that since it is a behavioral modeling technique. He asked what Si vendors thought about whether it's realistic to hide the equalization in a Tx or Rx model. Arpad noted that when IBIS itself was first proposed by Intel, the thought was that the table based behavioral model was wonderful and would protect IP. However, Intel later started releasing IBIS models under NDA only, because they found that the I-V and V-T curves themselves could just be used by competitors who then avoided having to do all the work to create their own. Arpad asked, if IP protection is no longer an issue, then is Walter's simplified version sufficient? Do we not have to pass in the crosstalk terms, or is Fangyi's point about the model optimizing based on crosstalk important? Arpad asked whether it's redundant to return the modified IR (existing flow) and the IR of the equalization itself. Couldn't the tool do everything itself if it had the IR of the equalization? Walter said this was only true for the Tx. For the Rx, the EDA tool can't do the DFE because the model would only return the IR of the analog front end (AFE). He said we could have the Rx model return two equalization IRs, one for the AFE and one for the DFE. Walter said this was a solution Fangyi had proposed during the original discussions on this topic a few years ago. Fangyi agreed, and said at that time we didn't assume every model had GetWave, so it was more complicated. Now perhaps we can assume all models are Dual. Walter agreed, but he said we don't require all models to be Dual. You can have Init only models at the beginning of the chain, but once you have a model with GetWave every model downstream also has to have GetWave. Arpad noted 3 variants that had been discussed today: 1. Fangyi's proposal (add cumulative upstream IR column to the input) 2. Walter's proposal (model returns additional IR of the equalization - only the part that would apply to crosstalk terms) 3. Model returns nothing but the filter IR(s) (perhaps AFE and DFE in separate IRs). Fangyi said his proposal was designed to minimize impact on the existing spec (no change to AMI function signatures). Walter said he thought his proposal had minimal impact, since we could just add a reserved parameter to indicate whether the model returns the crosstalk equalization IR. If it doesn't, or the tool doesn't recognize it, then it works on the existing tools with no changes. Arpad said we have the contentious case of a GetWave function that relies on the IR input to Init. He asked if that would be solved by any of the three options. Walter said you'd still have the issue of making sure each Init is getting the full upstream channel information. The only model that could have Init_Returns_Impulse=false would be the terminal Rx. Ambrish said we were now venturing from addressing statistical simulation flow with redrivers all the way to tackling a general time domain flow. He reiterated that the flow Walter just described (with a GetWave reliant on Init's input IR) was an overload of the Init function for the model maker's convenience/performance. A GetWave function should always be complete, and while it may take longer to converge without the right input to Init it must be able to deal with that possibility. He asked if we were really now going to legislate that all models (except the terminal Rx) must be Dual? Arpad said he had just asked the question to see if any of the 3 variants was preferable because it would handle the problematic case. Fangyi said that the last time we had discussed it, everyone except for Michael Mirmak seemed okay with assuming that every model has a GW function. Arpad recalled that Michael's primary concern was really that he wanted models to support statistical flow if at all possible. Fangyi said he would compile a comparison of the pros and cons of the variants. Arpad said this would be helpful, and asked him to add the comparison to his presentation slides. He suggested we hold off on posting today's presentation slides and post them after a future meeting when Fangyi has added the comparison information. - Curtis: Motion to adjourn. - Ambrish: Second. - Arpad: Thank you all for joining. AR: Fangyi to add comparisons of proposed variants of Init function input/output data to his presentation. ------------- Next meeting: 12 January 2021 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives